Azureのカオスエンジニアリングサービス Azure Chaos Studioをためしてみた

Azureのカオスエンジニアリングサービス Azure Chaos Studioをためしてみた

Clock Icon2021.11.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

Azureのカオスエンジニアリングサービス Azure Chaos Studioがパブリックプレビューで使えるようになりました。
Azureで構成されるワークロードに対して意図的に障害をインジェクションして回復性などの確認を行うことが出来ます。

なお、AWSワークロードに対してre:Invent2020にて発表された AWS Fault Injection Simulatorを使って類似のアプローチを行うことが可能です。

試す前に事前に確認しておきたい点

ポータルの言語が日本語だとエラーになる

実験作成のタイミングでエラーになりました。
すぐ修正されると思いますが、本日は部分的にEnglishに変更しています。

リソースプロバイダー登録が必要

Azureに慣れていると当然という感じだと思いますが、Azureではサービスごとにリソースプロバイダーの登録が必要です。(デフォルトで登録されているものとされていないものがある)

サブスクリプションのリソースプロバイダーメニューから登録可能です。

障害で操作するリソースの権限が必要

こちら設定は実験作成後になりますが、例えば仮想マシンに対して障害を発生させる場合は、実験に仮想マシンへのアクセス権限を付与する必要があります。
対象リソースでロールの割り当てを追加します。

ためしてみた

では、実際に試してみたいと思います。
仮想マシンを事前に作成済みとして進行していきます。

まず、障害を発生させる対象リソースのターゲットを有効にする必要があります。
ターゲットでは、サービス直接ターゲットとエージェントベースのターゲットの2種類が選択出来ます。
今回はエージェントレスなサービス直接ターゲットを有効化しました。

どちらのターゲットを有効化出来るかはサービスごとに異なっており、仮想マシンの場合はどちらも有効化することが可能です。

ターゲットを有効化した後は、「実験」を作成します。
実験は複数のステップから構成することが可能です。

このように、発生させることが出来る障害の種類は事前に定義されています。

現時点で対応しているプロバイダーは、ざっくりいうと以下のようです。

  • 仮想マシン
  • CosmosDB
  • AKS
  • NSG
  • Azure Cache for Redis

また、ターゲットによっても発生させることが出来る障害に違いがあります。
仮想マシンの場合はエージェントベースを使えばCPU負荷をあげたりすることも出来ますが、エージェントレスの場合は出来ませんでした。

今回はエージェントレスなので、仮想マシンを10分間強制停止するシナリオを選択します。

発生させる障害を選択したら、先程選択したターゲットを選択し、障害を作成します。

作成した実験がリストに表示されるまで少しタイムラグがあります。

実験の開始

作成した実験を選択し、「実験の開始」で実行出来ます。

確認してみると仮想マシンが停止されていることが確認出来ました。
実験のステータスはRunningです。

約10分後、実験のステータスがSuccessになりました。

そして、仮想マシンの状態もまた実行中に戻っていました。

さいごに

従来Azure環境でカオスエンジニアリングを行うためにはChaos Toolkitなどを利用する必要がありました。

カオスエンジニアリングのためのオープンAPIである Chaos Toolkitについて | DevelopersIO

今回Azureマネージドなカオスエンジニアリングサービスが登場したということで、かなりお手軽に障害発生をさせることが出来ました。
今回は試していませんが、障害発生時の通知や自動復旧など、回復性の確認などまで掘り下げたいですね。

サービス制限など詳細情報がドキュメントに記載されていますのでそちらもご確認ください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.